Mobile IPv6 (MIPv6), which is described in IETF RFC 3775, allows users of mobile communications devices to move from one network to another whilst maintaining a permanent IP address, regardless of which network they are in. This allows the user to maintain connections whilst on the move. For example, if a user were participating in a Voice Over IP (VoIP) session and, during the session the user moved from one network to another, without MIPv6 support the user's IP address may change. This would lead to problems with the VoIP session.
A Mobile Node (MN) is allocated two IP addresses: a permanent home address and a care-of address (CoA). The CoA is associated with an access network, an IP subnet, that the user is currently visiting. To communicate with the MN, packets are sent to the MN home address. These packets are intercepted by a Home Agent (HA) in the home network, which has knowledge of the current CoA. The Home Agent then tunnels the packets to the CoA of the MN with a new IP header, whilst preserving the original IP header. When the packets are received by the MN, it removes the new IP header and obtains the original IP header. The MN sends packets to another node by tunnelling them to the HA, encapsulated in packets addressed to the HA. For each packet, the HA removes the encapsulating packet, restores the original packet and forwards it to the intended destination node.
Proxy Mobile IPv6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-02, describes a Mobile Access Gateway (MAG) function. This function emulates home link properties in order to make a MN behave as though it is on its home network and allows support for mobility on networks that would not otherwise support MIPv6. A key difference between PMIPv6 and MIPv6 is that using MIPv6, a MN has control of its own mobility signalling, whereas using PMIPv6, a MN does not have control of its mobility signalling. The basic components of a PMIPv6 architecture are illustrated in FIG. 1.
A MAG 101 is usually implemented at the access router. The MAG 101 sends and receives mobility related signalling on behalf of a MN 102. When a MN 102 connects to an access router having a MAG 101, the MN 102 presents its identity in the form of a Network Access Identifier (NAI) as part of an access authentication procedure. Once the MN 102 has been authenticated, the MAG obtains the user's profile from a policy store. The MAG 101, having knowledge of the user profile and the NAI, can now emulate the MN's home network. The MN 102 subsequently obtains its home address from the MAG. The MAG 101 also informs the MN's 102 Local Mobility Anchor (LMA) 103 of the current location of the MN 102 using a Proxy Binding Update message. The Proxy Binding Update message uses the NAI of the MN 102. Upon receipt of the Proxy Binding Update message, the LMA 103 sets up a tunnel to the MAG 101 and sends a Proxy Binding Acknowledgement to the MAG. On receipt of the Proxy Binding Acknowledgement, the MAG 101 sets up a tunnel to the LMA, effectively forming a bidirectional tunnel. All traffic to and from the MN 102 is routed through the LMA 103 via the bidirectional tunnel. A MAG may serve many MNs associated with the same LMA. The MAG and the LMA do not need to have a dedicated bidirectional tunnel for each MN. Instead the same bidirectional tunnel can be used for the traffic of all the MNs that are associated with the same LMA and that are currently being served by the same MAG.
The LMA 103 intercepts any packet that is sent to the MN 102, and forwards the intercepted packet to the MAG 101 through the tunnel. On receipt of the packet, the MAG 101 removes the tunnel header and sends the packet to the MN 102. The MAG 101 acts as a default router on the access link. Any packets sent from the MN are sent via the MAG 101 through the tunnel to the LMA 103, which then sends the packet on to its ultimate destination.
Simultaneous Multi-Access describes a function of a communications network that allows a MN to combine different radio and/or fixed access technologies, as illustrated in FIG. 2. The MN 102 can simultaneously use several interfaces and different access networks (AN1 and AN2), which may employ different access technologies, in a communications session. Different traffic flows, belonging to different applications can be transferred between different access networks, independently of each other.
MIPv6 can be extended to support Simultaneous Multi-Access (see R. Wakikawa et al., “Multiple Care-of Addresses Registration”, Internet-Draft draft-ietf-monami6-multiplecoa-02, March 2007). Where more than one access is used, a MN has a CoA for each access. A Binding Unique Identifier (BID) is associated with each CoA, and the BID indicates which CoA a Binding Update (BU) relates to. If the BID associated with a new CoA is already in use, the new CoA replaces the one previously associated with the BID, whereas if the BID is not already in use, the new CoA is added to any previously existing CoAs. Since MIPv6 is host-centric (that is to say, the MN is in control of its mobility signalling), with all the mobility signalling flowing between the MN and the HA, the MN has a complete overview and complete control of how CoAs are added to or replacing each other, by assigning the BIDs appropriately.
Using PMIPv6, the MN is not in control of its mobility signalling. As described above, mobility signalling is handled by a MAG on behalf of the MN. A Proxy Binding Update (PBU) is triggered when the MN attaches to an access and the MAG responsible for the access. This means that a MN has no way of indicating its intentions regarding how the accesses are to be used in terms of PMIPv6, i.e. whether a new access should be added to the already used accesses or replace one or more old one(s).
In the absence of explicit intention indications from the MN, the PMIPv6 LMA can operate in either of two modes:
1. Simultaneous Multi-Access mode, where new CoAs are added to old ones and an old CoA is deregistered only when the MN detaches (explicitly or implicitly by losing contact) from the corresponding access.
2. Non-simultaneous multi-access mode, where only a single CoA is used at a time and a new CoA consequently replaces the previous one.
Although the description of the Simultaneous Multi-Access mode above clearly states that a new CoA should always be added to the existing ones and never replaces an old one, a problem can arise when a MN attaches to a new access and the MAG of that access registers a new CoA in the LMA. In accordance with the simultaneous multi-access mode the LMA will not deregister the old CoA(s). However, the reason for attaching to the new access might well have been that the MN lost an old (and possibly only) access. If this is the case, the MN has not explicitly signalled to the old access that it has detached (even if such means were available in the old access network) and the MAG of the old access has to rely on some kind of time-out or periodic check mechanism, e.g. neighbour unreachability detection (NUD), to detect the detachment before it deregisters the CoA in the LMA. Before the detachment is detected and the old CoA deregistered, the LMA may continue to send traffic to the old MAG, and so packets in that traffic are lost when forwarded to the no longer attached MN. It would be desirable to prevent this packet loss.